OTDS Resources and Trust

OpenText Directory Services (OTDS) is a product for identity management and user authentication across OpenText products. OTDS provides the Single Sign-On feature for the user across the OpenText products. Users can be managed in OTDS and information about the identity of a user can be exchanged between products that support OTDS. In OTDS, a user can have a different account for each product. OTDS has functionality that can map user accounts between different products. With this OTDS can provide authentication proof for a user account in one product based on the authentication proof of the same user in another product.

The OTDS feature in the Process Platform is useful when integrating with products authenticating against the same OTDS server. This integration can be both for a Single Sign-On inbound authentication from, for example AppWorks, or outbound authentication to, for example Content Server.

For these integrations with the Process Platform, a product must be registered in both OTDS Server and Process Platform. This registration is called a Resource. Resources are registered in OTDS and are identified by a Resource ID. Resources also need to be activated. In the activation process, OTDS provides Shared Secret. This shared secret is used in communication between the product and OTDS, as an expression of trust between the two products. During communication the user context must be transferred in a trusted way. OTDS provides its own proprietary protocol to exchange the authenticated user information between the products. 

Registering Resources

To register a resource, do the following:

1. Create a new Resource in OTDS Server and copy the new Resource identifier.
2. Create a new Resource in the Process Platform using the OTDS Server URL and the Resource identifier.
3. Activate the Resource in the Process Platform to link it with the OTDS Server Resource.

Depending on the requirements, multiple resources can be required:

• For incoming (inbound) messages, the Process Platform needs to register itself in OTDS Server as a Resource.
• For outgoing (outbound) messages, the Process Platform needs a Resource for every product it wants to send messages to, for example Content Server.

For more information, see Managing OTDS Resources.

Inbound Trust

Web-service requests received by the Process Platform can carry OTDS authentication information in the SOAP header, this is also called Inbound API Authentication. This OTDS authentication in the form of an OTDS ticket must be validated against the OTDS server that generated the information. As the incoming request does not carry information for which Resource it is targeted, this must be configured. The administrator has to specify which Resource must be used to validate the OTDS authentication information present in the SOAP header of the incoming requests. The configured Resource always must be a Resource linked to the Process Platform itself, as the other product is sending a message to the Process Platform.

A Resource must be trusted in the Process Platform for inbound authentication. After that other products can send Web service requests to the Process Platform and the OTDS authentication information is used as an authentication proof.  For more information, see  Managing OTDS Trust .

OTAuthentication SOAP Header

The OTDS Authentication information in the SOAP header actually is an OTDS ticket. The OTDS ticket must be specified in a node called OTAuthentication. For detailed information how to use OTDS Authentication for Inboud API authentication, see OTAuthentication SOAP Header.